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Remarks 

Applicant respectfully requests reconsideration of the present application in view of the 
foregoing amendments and the following remarks. Claims 1-17 are pending in the application. 
Claims 1-17 are rejected. No claims have been allowed. Claims 1, 10, and 13 are independent. 
Claims 1, 10 and 13 have been amended. 

Cited Art 

The Action cites: 

Kim et al., "Design and Implementation of Home Network Systems Using UPnP Middleware 
for Networked Appliances," IEEE Transactions on Consumer Electronics, Volume 48, Issue 4, Nov 
2002, pages 963-972 ("Kim publication"); 

Hite et al. (US Patent No. 7,213,061) ("Hite patent"); 

Kumar et al. (US Patent No. 7,017,148) ("Kumar patent"); 

Skingsley et al. (US Patent No. 6,697,751) ("Skingsley patent"); and 

UPnP Implementers Corporation, "UPnP Device Certification Process Document," 
Version 1.0, 2001) ("UPnPIC documentation"). 

Claim Objections 

The Action rejects claims 13 due to a typographical error. The error is corrected by 
amendment above. 

Claim Rejections under 35 U.S.C. § 102 

The Action rejects claims 13, 15, and 16 under 35 U.S.C. 102(a) as being anticipated by the 
Kim publication. The Applicant respectfully disagrees. Claim 13 is independent. 
Claim 13, as amended, recites: 

program code for, within the generic device emulator, receiving action requests 
directed to the device from a control point within the device connectivity architecture; 

program code for, within the generic device emulator, checking an action 
request, received from a control point, against the description to validate whether the 
action request matches that of an action specified in the description; and 
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program code for, within the generic device emulator, performing a default 
behavior producing a response for the action consistent with the data format specified 
in the description, thereby emulating operation of the device for the action. 

[Emphasis added.] For example, the Application describes a generic device emulator in example 

implementations receiving action requests in Section 3: 

In the control phase, the generic device emulator 210 implements default 
behaviors for the actions specified in the emulated device's service description 
document(s) 221. The generic device emulator 210 receives action invocation messages 
(SOAP commands) from control points and validates these messages against the 
emulated device's service description. Upon validation, the generic device emulator 210 
provides a default response to the action invocation, which response conforms to the 
data format and types specified in the service description for the action. For example, if 
the response to the action specified in the service description is to return an integer 
value, the default behavior simply returns a default integer value (e.g., a zero). 

[Application, at page 13, line 24 to page 14, line 2; emphasis added.] The Application also discusses 

control point specifics according to example implementations in Section 1 : 

Control Points 

A control point in a UPnP™ network is a controller capable of discovering and 
controlling other devices. After discovery, a control point could: 

• Retrieve the device description and get a list of associated services. 

• Retrieve service descriptions for interesting services. 

• Invoke actions to control the service. 

• Subscribe to the service's event source. Anytime the state of the service 
changes, the event server will send an event to the control point. 

The control points 1 10 - 111 and devices 130 - 132 can be any variety of device 
with embedded computing and networking capabilities, including without limitation 
audio/video or other multimedia recording/transmitting/receiving/or presenting device 
(broadcast receivers, televisions, video players, cameras, etc.), computers (personal, 
workstation, server, handheld, laptop, tablet, or other mobile), telephones, office 
equipment (printers, copiers, scanners, fax), security systems, home appliances 
(lighting, heating, ventilation, air conditioning, door openers, kitchen appliances, etc.), 
as a few general examples. 

The control points 1 10 - 111 and devices 130 - 132 each implement the UPnP™ 
device connectivity protocol. They include networking protocol stacks for 
communicating over the network 120 with other network actors. They also include 
network interfaces for interfacing with the network 120. 

[Application, at page 7, line 12 to page 8 line 9.] 
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The Kim publication's Home Server Program, which the Action cites against claim 13, does not 
teach or suggest "within the generic device emulator, receiving action requests directed to the device 
from a control point" and "within the generic device emulator, checking an action request, received 
from a control point, against the description " as recited in claim 13, because the home server is not an 
appliance emulator and addresses interaction with a user, not a "control point. " In its rejection of 
claim 13, the Action repeatedly cites to § 3, page 965 of the Kim publication, as well as associated 
Figure 2. [See, Kim publication, at § 8, page 3.] In particular, this section is cited against the claim 
language which corresponds to the language from claim 13 quoted above. 

This cited passage, however, refers to actions undertaken by the "Home Server Program" of the 

Kim publication and does not teach or suggest "receiving action requests directed to the device from a 

control point" and "checking an action request, received from a control point, against the description" 

as recited in the claim. For example, paragraph four of the cited portion describes the "Home Server 

Program" reacting to user interaction, rather than interaction from a control point: 

In the appliance section of the home server program display, simple information 
about each monitored appliance (the state variables) is displayed at the top. When the 
user invokes an action service using the action item in the device control frame, a 
message is sent to invoke the action. When successful, the updated state variables are 
displayed on the home server. 

[Kim publication, at § 3, page 965, fourth paragraph; emphasis added.] The "Action Invocation" loop 

of Figure 2, also cited here, states only the steps "Action Invocation?" "Request Action to device" and 

"Service State Variable related action Query and Display" which mirror the description from page 965 

quoted above. [Kim publication, at Figure 2.] 

Applicant first notes that, in previous prosecution, Applicant has argued that the "Home Server 
Program" of the Kim publication does not teach or suggest a "generic device emulator" as recited in 
the claim, as the "Home Server Program" of the Kim publication interacts with the Kim publication's 
individual "appliance emulators" rather than performing emulating activities. However, the Action, 
appears to find the actions of the claimed "generic device emulator" in the Kim publication's 
description of the "Home Server Program." Applicant has thus amended the claims to better clarify 
the interactions taken between actors in the claim language. 

Applicant respectfully notes that the cited passage does not teach or suggest "receiving action 
requests . . . from a control point" because it merely describes receiving action invocations from a 
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user. The described "Home Server Program" allows a user to "check[] all the UPnP-compatible 
appliances in the home network when the user invokes [a] search." [Kim publication, at § 3, page 965, 
first paragraph; emphasis added.] It also allows a user to obtain information about appliances and to 
invoke actions on the appliances. [Kim publication, at § 3, page 965, paragraphs 2-4; emphasis added.] 
The Action itself makes clear that it finds the recited "action requests" in user interaction in the 
"Response to Arguments" section where it states that "It is the Examiner's position that the 'action 
service' is the 'action request'." [Action at § 62, pages 22-23.] Thus, Applicant respectfully argues 
that the interactions with the "Home Server Program" cited against the language of claim 13 are user- 
initiated. Applicant further does not find any discussion in the Kim publication that these interactions 
are between a generic device emulator and a control point as recited in the amended claim. 

Applicant also notes that, while the Action occasionally cites to the "appliance emulators" 
described in the Kim publication, the description of these "emulators" do not satisfy the requirements 
of § 102. First, Applicant notes that the Action cites to § 4.2 of the Kim publication, which discusses 
implementations of the Kim publication's "appliance emulators" in its rejection regarding the 
"checking an action request" language of claim 13. However, the majority of the rejection cites, 
against the "receiving an action request" language of claim 13, the description of the "Home Server 
Program" as discussed above. Applicant respectfully suggests that it is inconsistent to find both the 
"checking an action request" and "receiving an action request" language in different devices in the 
Kim publication when the claim language puts both in the recited "generic device emulator." In 
addition, Applicant respectfully notes that for reasons discussed in previous prosecution, the whole of 
the "generic device emulator" language recited in claim 13 is not taught or suggested by the "appliance 
emulators" described by the Kim publication. 

For at least these reasons, the Kim publication does not teach or suggest each and every 
element in claim 13. Thus, the rejection of claim 13 over the Kim publication is improper. Applicant 
therefore requests that the rejection of claim 13, and of dependent claims 15 and 16, be withdrawn and 
that claims 13, 15, and 16 be allowed. The Applicant will not belabor the merits of the separate 
patentability of dependent claims 15 and 16. 
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Claim Rejections under 35 U.S.C. § 103(a) 

Claims 1-3 

The Action rejects claims 1-3 under 35 U.S.C § 103(a) as unpatentable over the Kim 

publication in view of the Hite patent. The Applicant respectfully disagrees with the rejections. 

Claim 1, as amended, recites: 

processing, in a generic device emulator able to emulate more than one device 
based on device descriptions, a description of a device to be emulated in the device 
connectivity protocol, the description specifying a set of actions of the device to be 
emulated; 

in response to receiving an action request from a control point at the device 
emulator per the device connectivity protocol, checking the action request against the 
device description in the device emulator to validate which action out of the set of 
actions specified in the description the action request matches; 

[Emphasis added.] In its rejection of claim 1, the Action cites to similar sections of the Kim 

publication as in the rejection of claim 13. For at least the reasons discussed above with respect to 

claim 13, the Kim publication does not teach or suggest the above-emphasized language of claim 1. 

Furthermore, Applicant does not find relevant disclosure in the Hite patent. The Hite patent 

discloses systems and methods relating to making "the boundaries between the Internet and the control 

area network . . . transparent and the Internet becomes a device on the control area network" [Hite 

patent at column 1, lines 32-35], but does not address device emulation as recited in claim 1. For at 

least these reasons, the combination of the Kim publication and the Hite patent does not teach or 

suggest every element of claim 1. Thus, the rejection of claim 1 over the Kim publication and the Hite 

patent is improper. Applicant therefore requests that the rejection of claim 1, and of dependent claims 

2 and 3, be withdrawn and that claims 1-3 be allowed. The Applicant will not belabor the merits of the 

separate patentability of dependent claims 2 and 3. 

Claims 10-12 

The Action rejects claims 10-12 under 35 U.S.C § 103(a) as unpatentable over the Skingsley 

patent in view of the UPnPIC documentation. The Applicant respectfully disagrees with the rejections. 

Claim 10 recites, in part: 

reading a device defect configuration file representing in a tagged text format at 
least one defect behavior to be applied to a type of packet transmitted as part of a 
message for a device emulated per the device connectivity protocol; 
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upon production of a valid packet for the emulated device, as part of a message, 
the valid packet being of a type for which a defect behavior is represented in the device 
defect configuration file, and before transmitting the valid packet, applying the defect 
behavior to the valid packet to create an invalid packet for the emulated device; 

[Emphasis added.] For example, the Application describes the work of the Defect Callback Handler 

object according to example implementations in Section 4: 

All the packets before being sent out on the socket are consulted with the Defect 
Callback Handler object 342. The user can implement methods to inject a defect or 
defects into the packets. This feature is extremely useful in testing control points. Each 
method will inject a defect or defects into a particular message type. The user creates a 
defect behavior type by specifying a set of such methods using the defect configuration 
file 350. 

[Application at page 18, lines 10-17; emphasis added.] As the Application notes, one benefit of this 

process is to test control points by the emulator device sending back malformed packets, which the 

control point must be able to handle. Specific example operations of the defective behavior framework 

according to example implementations are then described in Section 5: 

As discussed above, the generic device emulator 210 provides hooks 230 to add 
user-specified action implementations, which permits the user to build full (non-default) 
working implementations of the emulated device. This section will discuss methods by 
which defective packets can be injected into the UPnP™ conversation. After building a 
Packet to send out of the socket . . ., the generic device emulator gives a callback into 
the framework 300 . This callback gives control back to a user-provided defective 
behavior method that can malform the packet and send it back to the generic device 
emulator, which the generic device emulator then sends out through the socket. 

[Application, at page 21, lines 13-22; emphasis added.] The Action acknowledges that the Skingsley 

patent does not expressly teach "the defect configuration that represents a defect behavior being 

represented in a tagged text format" and "wherein applying the defect behavior comprises invoking a 

user-provided implementation of the defect behavior." However, the Action finds this in the UPnPIC 

documentation. [Action at §§ 47 and 48, pages 16 and 17.] 

The UPnPIC documentation, either alone or in combination with the Skingsley patent, does not 

teach or suggest the above-quoted language of claim 10, because the UPnPIC documentation 

describes, at most, the use of configurations to direct valid error messages, and not applying defect 

behavior to a valid packet to create an invalid packet for an emulated device" as recited in claim 10. 

In its rejection of claim 10, the Action cites to §§ 5.1 and 5.2 of the UPnPIC documentation, where the 

UPnPIC documentation describes UPnP testing. [Action, at § 48, pages 16 to 17.] The Action goes on 
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to note that the UPnPIC documentation describes syntax testing with reference to device descriptions 
as well as semantic tests. The Action also gives the example of testing of a VCR which is expected to 
produce an error message when the play button is pushed with no tape in the device. [See, Action, at § 
48, pages 16 to 17.] The Action appears to implicitly find, based on this example, the language against 
which the UPnPIC documentation is cited, determining that "in order for this behavior of the VCR to 
be tested, a text that produces this 'defect' behavior, . . . must be read an applied to the VCR in order to 
test the device, therefore, a 'device defect configuration file' is read that represents a 'defect behavior 
to be applied.'" [Id.] 

Applicant respectfully disagrees. Applicant first notes that the Action fails to find the language 
of the claim explicitly in the UPnPIC documentation, but must instead find it implicitly based on the 
outcome produced by testing. Applicant respectfully submits that successful testing in no way implies 
that a particular type of file was ever read by a device in order to produce the test results. Indeed, in 
the particular example given in the Action, there is no indication that the example device (the VCR) 
has any ability to read any sort of file like that recited in the claim, nor is there any indication found by 
the Applicant in the cited portions of the UPnPIC documentation that some sort of testing device that 
could read such a file is used. The Applicant finds no disclosure in the Skingsley patent to overcome 
this deficiency of the rejection. Applicant therefore argues that the Action fails to make a prima facie 
case of obviousness over claim 10. 

Furthermore, Applicant notes that the language of claim 10, as amended, describes packets as 
part of a message. As such, Applicant fails to see how the UPnPIC documentation and the argument 
in the Action, which describe the sending of entire error messages, would teach or suggest the above- 
quoted language of the claims. 

Finally, Applicant notes that combining the Skingsley patent with the UPnPIC documentation 
would render the UPnPIC documentation unsatisfactory for its intended purpose, which means the 
rejection is improper. [See, MPEP, 2143. 01(V).] The UPnPIC documentation is directed toward 
testing of UPnP device by reviewing outputs from the device to see if they conform with test 
requirements. [See, UPnPIC documentation, at §§5.1-5.3.] If the outputs of the device were modified 
by operating on the packets as the Skingsley patent teaches, the validity of the output messages 
themselves could not be determined. As such combining the Skingsley patent with the UPnPIC 
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documentation would prevent proper testing of the UPnP device, rendering the UPnPIC documentation 
unsatisfactory for its intended purpose. 

For at least these reasons, the rejection of claim 10 over the Skingsley patent and the UPnPIC 
documentation is improper. Applicant therefore requests that the rejection of claim 10, and of 
dependent claims 1 1 and 12, be withdrawn and that claims 10-12 be allowed. The Applicant will not 
belabor the merits of the separate patentability of dependent claims 1 1 and 12. 

Claims 4 and 5 

The Action rejects claims 4 and 5 under 35 U.S.C § 103(a) as unpatentable over the Kim 
publication in view of the Hite patent and further in view of the Kumar patent. Each of claims 4 and 5 
depend from claim 1. For at least the reasons described above, at least one element of claims 4 and 5 
is not taught or suggested by the combination of the Kim publication and the Hite patent. Furthermore, 
Applicant does not find relevant disclosure in the Kumar patent, which is directed to "UPnP device 
code generation using XML." [Kumar patent, at Abstract.] For at least these reasons, the rejection of 
claims 4 and 5 under § 103 is improper. In the interest of expediting prosecution, Applicant will not 
belabor the merits of the separate patentability of the individual dependent claims. Applicant 
respectfully requests that the rejection be withdrawn and that claims 4 and 5 be allowed. 

Claims 6, 7, and 9 

The Action rejects claims 6, 7, and 9 under 35 U.S.C § 103(a) as unpatentable over the Kim 
publication as modified by the Hite patent and further in view of the Skingsley patent. Each of claims 
6, 7, and 9 depend from claim 1. For at least the reasons described above, at least one element of 
claims 6, 7, and 9 is not taught or suggested by the combination of the Kim publication and the Hite 
patent. Furthermore, Applicant does not find relevant disclosure in the Skingsley patent, which is 
directed to testing and monitoring of data packets. [Skingsley patent, at Abstract.] For at least these 
reasons, the rejection of claims 6, 7, and 9 under § 103 is improper. In the interest of expediting 
prosecution, Applicant will not belabor the merits of the separate patentability of the individual 
dependent claims. Applicant respectfully requests that the rejection be withdrawn and that claims 6, 7, 
and 9 be allowed. 
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Claim 14 

The Action rejects claim 14 under 35 U.S.C § 103(a) as unpatentable over the Kim publication 
in view of the Kumar patent. Claims 14 depends from claim 13. For at least the reasons described 
above, at least one element of claim 14 is not taught or suggested by the Kim publication. 
Furthermore, Applicant does not find relevant disclosure in the Kumar patent, which is directed to 
"UPnP device code generation using XML." [Kumar patent, at Abstract.] For at least these reasons, 
the rejection of claim 14 under § 103 is improper. In the interest of expediting prosecution, Applicant 
will not belabor the merits of the separate patentability of the claim. Applicant respectfully requests 
that the rejection be withdrawn and that claim 14 be allowed. 

Claim 8 

The Action rejects claim 8 under 35 U.S.C § 103(a) as unpatentable over the Kim publication 
as modified by the Hite patent and further in view of the Skingsley patent and further in view of the 
Kumar patent and the UPnPIC documentation. Claim 8 depends from claim 1. For at least the reasons 
described above, at least one element of claim 8 is not taught or suggested by the combination of the 
Kim publication and the Hite patent. Applicant does not find relevant disclosure in the Skingsley 
patent, which is directed to testing and monitoring of data packets. [Skingsley patent, at Abstract.] 
Moreover, Applicant does not find relevant disclosure in the UPnPIC documentation, which is directed 
to testing of UPnP devices. [UPnPIC documentation, at §§ 5.1 and 5.2.] For at least these reasons, the 
rejection of claim 8 under § 103 is improper. In the interest of expediting prosecution, Applicant will 
not belabor the merits of the separate merits of the separate patentability of the claim. Applicant 
respectfully requests that the rejection be withdrawn and that claim 8 be allowed. 

Claim 17 

The Action rejects claim 17 under 35 U.S.C § 103(a) as unpatentable over the Kim publication 
in view of the Skingsley patent and further in view of the UPnPIC documentation. Claim 17 depends 
from claim 13. For at least the reasons described above, at least one element of claim 17 is not taught 
or suggested by the Kim publication. Applicant does not find relevant disclosure in the Skingsley 
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patent, which is directed to testing and monitoring of data packets. [Skingsley patent, at Abstract.] 
Applicant does not find relevant disclosure in the UPnPIC documentation, which is directed to testing 
of UPnP devices. [UPnPIC documentation, at §§ 5.1 and 5.2.] For at least these reasons, the rejection 
of claim 17 under § 103 is improper. In the interest of expediting prosecution, Applicant will not 
belabor the merits of the separate patentability of the claim. Applicant respectfully requests that the 
rejection be withdrawn and that claim 17 be allowed. 

Interview Request 

If the claims are not found by the Examiner to be allowable, the Examiner is requested to call 
the undersigned attorney to set up an interview to discuss this application. 

Conclusion 

The claims in their present form should be allowable. Such action is respectfully requested. 



Respectfully submitted, 



KLARQUIST SPARKMAN, LLP 



One World Trade Center, Suite 1600 
121 S.W. Salmon Street 
Portland, Oregon 97204 
Telephone: (503) 595-5300 
Facsimile: (503) 595-5301 



By /Kyle B. Rinehart/ 
Kyle B. Rinehart 
Registration No. 47,027 
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